home *** CD-ROM | disk | FTP | other *** search
Text File | 1997-02-28 | 36.8 KB | 1,001 lines |
- !FreeSMTP 1.21
- ==============
-
- Contents:
- Copyright & Disclaimer
- Important Changes in this Version
- Installation Instructions
- Upgrading from Earlier versions
- Configuration Instructions
- Why does all email get sent to "localhost"
- Operating Advice
- for people with permanent links
- for people with transient dialup links
- Running & Stopping !FreeSMTP
- What to do if you get the error message:
- Loopback interface is not configured/up
- Loopback interface is configured - but not up
- Kicking the sender
- Activity log
- References
- Bug Reporting
- Technical Details
- MX records explained
- Security Considerations
- Ident
- ChangeLog
-
-
- **** WARNING: Incorrect configuration can cause you to be in breach
- **** of your provider's terms & conditions. Full details under the
- **** configuration section below, in the subsection "forwarder"
-
-
-
-
- Copyright & Disclaimer
- ----------------------
-
- This program is copyright (C) Stewart Brodie, 1996, 1997
-
- The author accepts no liability for any damage or loss of any kind incurred,
- or allegedly incurred, by the use, or misuse, of this software. The program
- may do its absolute best to ensure that incoming mail is either stored
- successfully in the incoming (or outgoing) mail spool appropriately, or that
- the sender is informed that the delivery attempt was unsuccessful and should
- be retried (or not as appropriate).
-
- Having said all that, I do want people to use it and find any problems. I'm
- afraid that some people's attitude make all those disclaimers necessary. For
- normal usage, there shouldn't be any problem, and the programs try very hard
- indeed to prevent any loss occurring (eg. by not acknowledging successful
- reception of an e-mail until it has been successfully stored in the spool
- directory completely). If the program fails, then in the vast majority of
- cases the upstream SMTP will have received a rejection from this program
- (unrequested connection termination counts as a rejection unless the 250
- response to the final '.' of a DATA body is received at the sender). If the
- sender half of this software fails, then it it will construct a failure
- message and return that directly to the message originator.
-
-
-
- Important Changes in this Version
- ---------------------------------
-
- Issuing a DATA command at the wrong point no longer results in two responses
- being sent.
-
- From older versions:
-
- A bug whereby the sender fails to start due to a memory shortage and then
- will never start again (until FreeSMTP is reloaded) has been cured.
-
- I've implemented a fix for the forwarding rules which should make the
- forwarder lines behave completely intuitively. If people find problems,
- I'd like to know bout them, please.
-
-
- Installation Instructions
- -------------------------
-
- Installation should be fairly simple and trouble free provided these
- instructions are followed carefully. You will NEED Newsbase 0.55 or later
- in order for this to work properly - it will not like 0.54. I have tried
- to include as much details as possible, so don't worry about the apparent
- length of it.
-
- * Copy the Transports directory into the !Newsbase directory to install the
- interface programs in Newsbase. (You may find that you have to restart
- Newsbase now to get it to recognise the newly present transport).
-
- * Copy the !FreeSMTP directory into a directory containing your other
- Internet applications, and run it in its new home (it will fail to start
- because there is no configuration file, but this step is necessary in
- order to reset the system variables to point to the correct directory)
-
- * Open the Newsbase Transport Control window, and in the middle portion
- of this window, choose "in_smtpd" off the Transport menu. You should now see
- the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar. If
- you fail to get this far, then you may have forgotten to restart Newsbase or
- to rerun !FreeSMTP.
-
- * Switch on the Check arrivals new mail option.
-
- * Follows the instructions in the Configuration Instructions below
-
- * Ensure you have a DNS resolver configuration file. If you do not have a
- DNS resolver installed on your system, then you will need to get one. You
- can find this out by looking for a file in !Internet.Files (or
- !FreeUser.Files or !InetSuite.Internet.Files) called "resconf". If this is
- present, then you have already got the necessary file installed. The
- resolver module is NOT used, but the configuration file it uses IS used by
- these programs (FreeNet (by Tom Hughes) comes with InetDB and its
- installation instructions; ArcWeb (my program) comes with just the
- installation instructions necessary)
-
-
- Upgrading from Earlier versions
- -------------------------------
-
- Reinstall the Transports into !Newsbase. If you changed the log file
- locations in !Run, re-edit the *new* !Run since this contains new
- system variables that are required.
-
- Your mail is received into a different directory than before version 1.14.
- This makes it compatible with the KA9Q directory structure.
-
- You should read the section on 'noiconbar' in the configuration section as
- this is a new command.
-
-
- Configuration Instructions
- --------------------------
-
- There is a single configuration file for !FreeSMTP which is stored
- inside the !FreeSMTP directory. This is deliberately entirely made
- up of comments so that the programs will refuse to load before you
- have edited the configuration. You should find that you can skim
- through this section, modifying the file as you go.
-
- (If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
- in the same directory, or click on Setup in the Newsbase Transport Control
- window which will do this for you)
-
- The configuration file is a sequence of directives which tell the
- software what your machine's real name is, what e-mail domains it
- hosts, and which domains it relays mail for (if any). I have tried
- to provide as much flexibility as possible whilst keeping it as
- simple as possible for the vast majority of cases (take a look at an
- /etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)
-
- To edit the configuration file, choose the "in_smptd" transport in the
- Newsbase "Transport Control" window. You should then see the description
- message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)". To set up the Newsbase
- bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
- set, and a smarthost is placed in the gateway box for mail(**). Also set
- in_smtpd as the Def mail route. Then, you should click on the Setup button
- which will open the configuration file in your text editor ready for you
- to set your own site details.
-
- (**) If you set the gateway to be your own machine, then you MUST have
- an appropriate forwarder line as described below. The line you
- will need will be "forwarder * provider's-smarthost".
-
- Provided you have set up the forwarder lines, you can tell any software
- you have to send outgoing mail to 'localhost'. This will result in it
- being sent to the server which will then route it using the rules in
- smtp-conf without consulting Newsbase.
-
- There are brief comments in the configuration file to remind you what each
- section is for, but these are elaborated here. The order of the sections is
- not important, although the order of declarations of the same type IS
- important (see below for reasons) For each section I have given the syntax,
- an example for a Demon DialUp user with a nodename of 'customer',
- (applicable to other static IP single host systems too), an example for a
- host on a network handling mail for that network, and my own setup.
-
-
- hostname
- ========
-
- Syntax: hostname <Fully Qualified Domain Name (FQDN)>
- Demon DU: hostname customer.demon.co.uk
- Network: hostname mail.an.org.uk
- My Setup: hostname delenn.ecs.soton.ac.uk
-
- This gives the *full* hostname(s) of the machine running this software.
- Hosts may have more than one name in some circumstances, and this is
- allowed by having multiple hostname lines, although the *first* line
- found in the file is the one used to identify the server to remote
- hosts when it needs to (eg. when greeting SMTP clients)
-
- localdomain
- ===========
-
- Syntax: localdomain <Fully Qualified Mail Domain> [<alias name>]
- Demon DU: localdomain customer.demon.co.uk
- Network: localdomain an.org.uk
- My Setup: localdomain delenn.ecs.soton.ac.uk soton
-
- [and in My Setup, <SMTPServer$Aliases>.soton contains the line:
- S.N.Brodie snb94r
- ]
-
- This gives the local *mail* domain(s) handled by the software. These
- mail domains are the things you see after the @ in mail addresses.
- When mail arrives, the destination is checked to see if there is any
- @ character in it. If there is NOT, then the value of the *first*
- localdomain directive is assumed. (This is so that the alias and user
- list functions can determine which set of aliases to apply)
-
- Next, the bit after the @ is compared against each localdomain directive in
- turn. If it matches any one of them, then the domain part is dropped. Next,
- if an alias name was specified for that localdomain, then the bit before the
- @ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
- and if so, the mail address is rewritten to match the definition of the
- alias. The format of that file is described below. You MUST be careful with
- that file.
-
- Otherwise, the bit before the @ is assumed to be a mailbox in the local
- Newsbase. (If no domains match, then it is checked against the forwarders
- below).
-
- If you wish to have an mailbox name that contains characters illegal in RISC
- OS filenames, then you can create an alias to convert it to something else,
- like I do in my alias file as shown above.
-
- For single dialup hosts, there is likely to be a single setting which
- will happen to co-incide with the hostname. For hosts serving entire
- domains, this is less likely. (Note that in My Setup, I accept mail for
- an unofficial mail domain - you won't find an MX record in the DNS for
- the delenn.ecs.soton.ac.uk mail domain)
-
-
- alias file format
- =-=-=-=-=-=-=-=-=
-
- The format of the file is that the alias appears first on the line, and
- the real addresses are specified after it separated by whitespace. If
- you need to use more than one line, then these continuation lines MUST
- start with whitespace (otherwise they are considered to be other aliases)
-
- Although this might seem like a good way to set up a mailing list, this
- is NOT the case, since the original sender will be in the FROM envelope,
- so any forwarding errors will go to there and not to some mailing list
- software.
-
- The purpose of the alias file is for *simple* rewriting and occasional
- duplication if you need it. If you want to run a mailing list, then
- use something like !MailList.
-
- So in My Setup mentioned above shows that any mail incoming addressed
- to S.N.Brodie@delenn.ecs.soton.ac.uk will be sent to snb94r. This is
- useful because you can specify names which might not be acceptable as
- usernames to Newsbase.
-
-
-
- forwarder
- =========
-
- Syntax: forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
- Demon DU: forwarder * post.demon.co.uk
- Network: forwarder * MX
- forwarder * mail.smarthost.provider.org
- My Setup: forwarder ecs.soton.ac.uk MX
- forwarder * dsse.ecs.soton.ac.uk
-
-
- This gives mail domains which are to be responded to by the software, but
- which are not local to this machine (ie. they need to forwarded on somewhere
- else, cf. localdomain). For the vast majority of people, you will want one
- forwarder line (see WARNING below - having such lines may in fact
- contravene your provider's terms & conditions of service unless you have
- specifically purchased the right to forward mail).
-
- The major purpose of the non-* entries here is when you are running FreeSMTP
- on the mail gateway for a domain (ie. the MX record for a domain gives
- the machine running FreeSMTP as one of the mail exchangers).
-
- If there are no forwarder lines, then any mail not destined for local
- delivery (ie. it matched one of the localdomain lines) will be rejected when
- it is offered by another host (*).
-
- If there are forwarder lines, then they are matched in order. If the first
- parameter is "*", then this matches, otherwise the string has to match the
- bit after the @ in the destination of an incoming mail exactly. The second
- parameter describes how this forwarding is to be achieved and is either the
- string "MX" or the FQDN of a smarthost which will do the job for you.
-
- There are two ways of forwarding the mail - MX records, and smarthosts. Using
- MX records involves looking up the name of the machines which handle mail for
- a given mail domain (see description later in this document) and then sending
- the mail directly to one of those machines. The alternative is to use a
- 'smarthost' (such as post.demon.co.uk) which will perform that function on
- your behalf (ie. it acts as an intermediate relay for you). The advantage of
- using MX records, is that it bypasses your provider's smarthost (less hops to
- the destination) and can tolerate the smarthost being down. When MX lookups
- return multiple records, they are tried in turn according to the priorities
- specified by the DNS server. [This does seem to work, as I found out when
- Demon's punts weren't accepting mail and when the connection attempt to them
- timed out, it sent it to relay-1 instead :-) ]
-
- (*) 'another host' could actually be your own machine. For example, I
- have ArcWeb's Email configuration set up with a smarthost mail gateway
- of "localhost". This means that ArcWeb will send mail by talking to the
- SMTP server process running on my own machine. Thus, having no forwarder
- lines in my configuration would mean that I couldn't send mail that way
- and would have to configure a remote smarthost in ArcWeb instead.
-
-
- forwarder strategy
- -=-=-=-=-=-=-=-=-=
-
- The forwarder directives which specify MX records are to be used are
- overridden in some circumstances, primarily for performance reasons.
-
- If the mail has only a single recipient (or multiple recipients with the same
- domain) and forwarder says to use MX records, and those MX records exist,
- then this will happen.
-
- If the mail has multiple recipients, then any MX directive is overridden and
- a smarthost is used instead *if one is defined* (because otherwise the
- message would have to be sent separately to each recipient). [A future
- enhancement will be to still use MX records if all the destinations share a
- common mail exchanger]
-
-
- WARNING: Incorrect configuration of forwarder records could cause you
- to be in breach of the terms & conditions of your account.
- Unless you are authorised to forward mail to hosts other than
- those at your provider's end of your connection, you should
- only have one forwarder line:
-
- forwarder * post.demon.co.uk
-
- (where you have substituted your provider's smarthost for
- post.demon.co.uk if you aren't with Demon Internet)
-
- The author accepts no responsibility or liability for any
- such breaches of terms & conditions, nor for consequences
- arising from action taken by providers against any user of
- this software for such breaches even if the author has been
- advised of the possibility of such breaches.
-
-
- acceptfrom
- ==========
-
- Syntax: acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
- Demon DU: (no acceptfrom lines)
- Network: (no acceptfrom lines)
- My Setup: (no acceptfrom lines)
-
- ** WARNING: If you use hostnames with this command, then these must be
- ** resolvable when the program starts, otherwise the directive
- ** will be ignored.
-
- This is used to selectively choose which remote hosts you are willing to
- accept mail from. If a host other than one listed attempts to deliver
- mail to your machine, then it will be told that it does not have permission
- to deliver mail to your machine. If there are no acceptfrom lines (as in
- My Setup) then any host may connect.
-
- When specifying an IP address, you may specify the number of significant bits
- to be matched (as described in the rejectfrom section below)
-
- All addresses that pass the acceptfrom directives (including the case
- where there are NO acceptfrom directives) are then validated against
- the rejectfrom directives described in the next section.
-
- IMPORTANT: If you have any of these fields, then you MUST include
- all the machine's own IP addresses and you MUST include localhost (ie.
- 127.0.0.1), since the outgoing sender may use these addresses when
- constructing error notifications and performing mail rewriting.
-
- There is little real reason to use this facility unless you are worried
- about faked e-mail being sent via your site (and even then, the message
- is tagged with the Received line containing the IP address of the sender,
- allowing you to trace the source)
-
- See also: rejectfrom, killfile
-
- rejectfrom
- ==========
-
- Syntax: rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
- Demon DU: rejectfrom 198.81.0.0/16
- rejectfrom 152.163.172.0/24
- Network: rejectfrom relay.deliverer.hackers.org
- My Setup: (no rejectfrom lines)
-
- ** WARNING: If you use hostnames with this command, then these must be
- ** resolvable when the program starts, otherwise the directive
- ** will be ignored.
-
- This is used to selectively choose which remote hosts you are NOT willing to
- accept mail from. If a host covered by one of these directives, then it will
- be told that it does not have permission to deliver mail to your machine. If
- there are no rejectfrom lines (as in My Setup) then any host may connect
- (subject to the acceptfrom conditions). The Demon DU example describes that
- mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
- are the AOL mail exchangers :-) I am not suggesting that you do this - just
- using it as an example of use.
-
- IMPORTANT: You should not reject any of your machine's own IP addresses
- (including 127.0.0.1 (localhost)). See also: acceptfrom, killfile
-
- There is very little real reason to use this facility unless you have
- some hacker trying to send you mail, in which case you can block their
- IP address using this facility.
-
-
- killfile
- ========
-
- Syntax: killfile <Fully Qualified Kill File path name>
- Demon DU: killfile smtpserver:killfile
- Network: killfile smtpserver:killfile
- My Setup: killfile smtpserver:killfile
-
- This is used to kill incoming mail based on the *sender* specified
- in the SMTP envelope (ie. the MAIL FROM). The file named in the
- directive is consulted when a new transaction is started and if
- the sender matches any entry, the mail is rejected.
-
- The kill file format itself is one (wildcardable) address per line.
- If the kill file does not exist, nothing is killed.
-
-
- noexpand
- ========
-
- Syntax: noexpand
- Demon DU:
- Network: noexpand
- My Setup:
-
- This directive is optional and takes no parameters. If it is present,
- then clients attempting an EXPN on an alias will receive a message
- indicating that EXPN has been explicitly disabled by the administrator.
-
- If you don't understand the above paragraph, then you don't need this.
-
- Normally, you'd only use this to stop people looking up the members of
- a mailing list of something like that. The vast majority of people
- do not want this.
-
-
- noident
- =======
-
- Syntax: noident
- Demon DU:
- Network: noident
- My Setup:
-
- This directive is optional and takes no parameters. If it is present,
- then the server will not attempt an ident request to the client making
- the connection. See "Remote User Authentication" section below for
- more details of ident.
-
- If you don't understand the above paragraph, then you don't need this.
-
- You would only ever disable this feature for efficiency reasons.
-
- noiconbar
- =========
-
- Syntax: noiconbar
- Demon DU: noiconbar
- Network:
- My Setup:
-
- This directive is optional and takes no parameters. If it is present,
- then no icon bar icon will be installed.
-
- You would only ever disable this feature to avoid filling your iconbar.
- If you have this directive, the only way to stop FreeSMTP is to double-
- click on FreeSMTP again.
-
-
- maxhops
- =======
-
- Syntax: maxhops <maximum hop count>
- Demon DU:
- Network:
- My Setup:
-
- This directive is optional and defaults to "maxhops 30". The numeric
- parameter describes the maximum number of servers through which the mail is
- allowed to be passed before being returned to the sender as undeliverable.
- Usually, mail will take at most half a dozen hops to get to the recipient.
- If it is up to something more like 30 (the default here), then it is likely
- that a mail loop has developed (a set of servers (mis)configured to route
- mail for the destination domain to each other, which will just keep
- forwarding it back and forth forever and ever). Once maxhops is exceeded,
- this server will not forward it any more, but will construct a delivery
- failure message and bounce it back to the sender.
-
- Almost certainly, you do not want to override the default.
-
-
- maxsessions
- ===========
-
- Syntax: maxsessions <+ve integer>
- Demon DU: maxsessions 4
- Network: maxsessions 4
- My Setup: maxsessions 4
-
- This specifies the maximum number of sessions that may be in progress at
- any one time. This is limited by the capability of the C library (and if
- you specify a number too large, it will be reduced to the maximum that can
- be supported - 4 with the current SharedCLibrary.
-
- It is important to have this set to 4 for Demon customers, since Demon
- have multiple mail machines which may attempt delivery concurrently.
-
-
- Why does all email get sent to "localhost"
- ------------------------------------------
-
- All e-mail sent by your machine will be sent initially to the server on your
- machine. (tech: the GATE command in the work file will always be set up
- to be "GATE VIA:localhost"). This is deliberate, because all the mail
- routeing cleverness is stored in the *server* at the moment. That software
- can then make the final destination decision and requeue it for sending out.
-
- This will cause an extra Received header to be placed in the outgoing mail,
- and will also ensure that missing headers are inserted before the mail
- leaves your machine too.
-
- This is not a really peculiar thing to do. Most UNIX machines I have used
- have done this. It is done to simplify the coding of the mail senders and
- to centralise the decision making process and forwarding rule processing
- into a single place so that policy changes can be implemented in one go.
-
-
- Operating Advice
- ----------------
-
- for people with permanent connections
- =====================================
-
- Run it all the time - that's what I do.
-
-
- for people with transient dialup links
- ======================================
-
- You really do want to start the TCP/IP stack and !FreeSMTP *before*
- connecting to the net. This is particularly important for Demon users, since
- the SMTP server takes around 1 second to start up and read its configurations
- files and may not manage to start listening for the incoming connections
- before the punts attempt to deliver mail (they fail to do so, and hold on to
- it for a while before trying again a bit later). This causes a slight
- problem with dialup lines though unless you are careful. You *must* start
- the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
- you do, your dialler won't be able to access the comms port!). The relevant
- bits that must be deferred until after dialling is complete are the slattach
- & ifconfig commands
-
-
- Running & Stopping !FreeSMTP
- ----------------------------
-
- Run !FreeSMTP by double-clicking on the icon in the directory viewer.
- To stop, it double-click on the icon again (or kill SMTP Monitor in
- the Task display window) or choose Quit from the icon bar menu if you
- haven't disabled the Wimp interface (see "noiconbar" directive above)
-
-
- What to do if you get the error message:
- Loopback interface is not configured/up
- Loopback interface is configured - but not up
- -----------------------------------------------------
-
- These two messages are new in version 1.17. If you get them, then you
- will find that the program will not have started. FreeSMTP needs the
- loopback interface configured. This should have been done during your
- boot sequence, or whenever the TCP/IP networking software was loaded.
-
- If you get the latter of the messages (which would be unusual unless
- you were fiddling around), then you need to issue the command:
- "*ifconfig lo0 up" at the command line or insert this in the networking
- startup files.
-
- If you get the former, then you need to insert the slightly longer:
- "*ifconfig lo0 inet 127.0.0.1 up".
-
- Once these commands have been executed, FreeSMTP should load. If it
- still doesn't, then the chances are you that are using an old version of
- FreeNet. Edit !FreeSMTP.!Run and insert the following line:
-
- Set SMTPServer$NoSearch 1
-
-
- (See also: Why does all email get sent to "localhost")
-
-
-
- Kicking the sender
- ------------------
-
- The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
- after in_smtpd has queued a mail in the outgoing queue, or the sendmail
- Newsbase transport has queued a mail there. You can kick it by choosing
- "Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
- !SendSMTP (inside !FreeSMTP).
-
- After being loaded, it will wait 30 seconds, then 1 minute, then 2, 4, 8,
- then 16 minutes, and thereafter every 30 minutes. This is in addition to the
- other times when it is kicked manually or by the server.
-
-
- Activity Log
- ------------
-
- This software contains inbuilt activity logging which it will dump to
- the files clnt_log & mon_log inside the !FreeSMTP directory.
- The amount of debugging and which debugging is controlled by a file called
- area_log, also inside !FreeSMTP. This contains one string per line
- containing a case-sensitive string to match against those used in the code.
- (* is used as a wildcard which matches every string). Examples of these are:
-
- domain_init
- process_mail
- verify_dest
-
- Vital messages are always logged if possible. The file is left open
- whilst the server is actively writing to it and closed after a short
- delay if nothing is written to it, for efficiency reasons. The location
- of the log file can be altered by editing !Run and changing the settings
- of the three <SMTPServer$xxxxxLog> variables.
-
- These will need to be cleared out every now & again.
-
- If you place a line containing just a single * character in this file, then
- everything will be logged to this file, this will help provided more details
- if you are having problem. If you send me this file when reporting faults,
- then it is more likely that I shall be able to help. If you do this, then
- the log file will grow very quickly. Only use it when attempting to capture
- debug trails for me.
-
-
- References
- ----------
-
- RFC821 - Simple Mail Transfer Protocol
-
- RFC1123 - Requirements for Internet Hosts
-
- RFC1413 - Identification Protocol
-
-
- Bug Reporting
- -------------
-
- There are bug reporting features built-in to the software. If you edit
- the file !FreeSMTP.area_log and add a new line at the bottom containing
- just an asterix (*), then all debugging information will be sent to the
- files, and not just the really important ones. These document some of
- the decisions made by the software and will contain justification for
- those decisions.
-
- Please give as much detail as possible when reporting bugs. Include the
- e-mail message that caused the problem if possible. NOTE: If you do not
- wish to disclose the identities of the sender/recipient, then please feel
- free to overwrite it with something else - use * characters for example -
- but please do NOT just remove it. If you do choose to delete parts of it,
- then please only delete the bits before the @ in the address. You may
- also like to remove most of the message body.
-
- Bug reports to S.N.Brodie@ecs.soton.ac.uk please
-
-
- Technical Details
- -----------------
-
- I have included this section for those who are interested. It does not
- matter if you do not want to read any more of this document.
-
- MX Records Explained
- ====================
-
- Briefly. You are probably familiar with the concept of hostnames (eg.
- customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk). The mappings
- between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
- registered in the Domain Name System's 'A' records (A for address). Mail
- domains look very much like hostnames, and in some cases happen to be the
- same, but this is coincidence (but arranged like that because it's easier to
- remember :-) Mail domains are also registered in the Domain Name System,
- but they do NOT map to IP addresses, but to 'Mail eXchangers'. These mail
- exchangers are simply the hostnames of machines which handle mail for that
- mail domain. For example, when software is using MX records to send me mail,
- it looks up the MX records for 'ecs.soton.ac.uk'. The response it will get
- will be something similar to:
-
- ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
- ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
-
- This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
- have the address 152.78.64.201) is a machine which handles mail for
- 'ecs.soton.ac.uk'. landlord.ecs.soton.ac.uk is also reported as a mail
- exchanger (so when bright is down, we can still receive mail), but the lower
- number indicates that bright is the preferred exchanger, and landlord the
- backup. If you perform a similar lookup on any Demon customer domain,
- usually you will find 4 or 5 records, with varying priorities. Although it
- would appear that lots of DNS lookups are required in order to find the
- addresses of these mail exchangers, that is not the case typically, as the
- full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
- (if not querying one of our authoritative nameservers in Southampton):
-
- Questions:
- ecs.soton.ac.uk. IN MX
-
- Answers:
- ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
- ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
-
- Additional:
- bright.ecs.soton.ac.uk IN A 152.78.64.201
- landlord.ecs.soton.ac.uk IN A 152.78.114.230
-
- Authority records:
- dns0.ecs.soton.ac.uk inet address = 152.78.64.201
- dns1.ecs.soton.ac.uk inet address = 152.78.114.230
- dns0.brad.ac.uk inet address = 143.53.240.2
- dns0.brad.ac.uk inet address = 143.53.2.5
- dns1.brad.ac.uk inet address = 143.53.238.5
-
- ie. since it is assumed that you will probably want the IN A record for
- each mail exchanger, the DNS server includes those records in its answer
- which you may need. Since you may not 'trust' the nameserver, it also tells
- you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
- internet domain. The auth records show the names of our primary and
- secondary DNS servers, plus our offsite authority nameserver (an Internet
- requirement) at Bradford.
-
-
- Remote host authentication
- ==========================
-
- When a connection is accepted, the peer IP address is looked up in the DNS.
- Since this lookup is initiated immediately, then the lookup is often
- complete before the HELO arrives (and the HELO parameter can thus be
- authenticated immediately). The domain name specified as the parameter to
- HELO is used in the Received header which is added by the smtp server to
- the incoming message, together with either the IP address of the remote
- host, or the name as obtained from the DNS.
-
- NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
- This is RFC-compliant behaviour (it is not allowed to reject on the basis
- of the HELO domain).
-
-
- Remote user authentication
- ==========================
-
- When a connection is accepted, then an ident request is sent to the origin
- machine requesting the user identity of the sender. (This is not done if
- the configuration file contains a "noident" directive). This is logged
- with area "ident" (so place "ident" in area_log to see it in smtp_log).
-
- NOTE: You cannot rely on this, particularly on the user id returned. See
- RFC1413 for more details about the (lack of) confidence that you should
- have in the ident response.
-
- NOTE 2: You might decide to disable this, but usually only because the
- overhead of establishing a TCP connection to the client wastes resources.
- The bandwidth used is negligible though (on average about 10 bytes out,
- and 25-50 bytes back).
-
-
- Attacks & Security Considerations
- =================================
-
- Simple denial of service attacks are prevented (limits on number of
- recipients for message plus limits on number of concurrent connections)
- The recipient limit is set to 100 (minimum requirement in RFC821)
-
- Idling attacks are repelled by implementing the timeout strategy given
- in RFC1123.
-
- Well faked e-mail can never be detected successfully, but the addition
- of the Received header to incoming message bodies will assist in the
- tracing of injection points into the SMTP system.
-
- Two log files are generated inside !FreeSMTP. These are called
- clnt_log and mon_log, and are generated by the client and monitor+server
- respectively.
-
- For the general mail security considerations see RFC821 and RFC1123. In
- the RISC OS environment, a further consideration is that being a single-
- user operating system, there is no way to prevent the Newsbase being
- examined directly, or the outgoing queue to be examined, unless you have
- taken specific measures to make this so.
-
- RFC1123 Considerations
- ======================
-
- Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
- rewritten as per RFC1123 to strip unnecessary source routeing from them.
- This happens before any other processing. (This also has the effect of
- stopping hackers using source routeing as a way of using you as a mail
- gateway, since after the rewrite, the destination domain will no longer
- match a localdomain, and will be rejected unless you forward for that
- domain)
-
- The %-hack is supported by the address rewriter too and explicitly
- removed, so hackers can't use that either.
-
- Miscellaneous
- =============
-
- When spooling files if the file cannot be opened in spool.mail.text.user then
- spool.fail.user is used instead (and the mail is bounced if that fails too).
- Files in spool.fail.user are never touched again and need to be handled
- manually.
-
- I am very interested in RFC compliancy issues. E-mail
- me any issues you find.
-
-
- ChangeLog
- =========
-
- 1.20
- ----
-
- Forwarding rules code clarified - shouldn't make as many mistakes.
-
-
- 1.19
- ----
-
- Loopback interface is checked for presence and uppishness
-
- Low memory situations are handled better.
-
- Miscellaneous fixes.
-
-
- 1.16
- ----
-
- The smtp_log left open problem is definitely gone now, because the file is
- gone too! Everything is dumped in mon_log instead.
-
- Aliases with capital letters in now work
-
- The forwarder doesn't consider you a twat for not using MX records and
- constantly override that decision. :-)
-
-
- 1.14
- ----
-
- Local spool directory changed to be spool.mail.text.*
-
-
- 1.13
- ----
-
- Bug in sender fixed - it was treated the successfully connection being made
- to the server as an error :-/
-
-
- 1.12
- ----
-
- Full release of the not grabbing all processing time version. Also
- contains a bug fix that cures a misinteraction caused by two concurrent
- mail deliveries. Log file closing finally sorted. However, because of
- the fix, you can't view smtp_log whilst the server is running.
-
-
- 1.10
- ----
-
- Should be better behaved and not grab as much processor time, which should
- help people using dialup links
-
- 1.09
- ----
-
- Log file should be closed successfully now
-
-
- 1.06
- ----
-
- Mail can now be sent even without a terminating linefeed. This would have
- caused mail to not be delivered.
-
- 1.05
- ----
-
- DNS Resolver bug fix
-
- 1.04
- ----
-
- RFC compliancy fix: doesn't try the A record if all the MX records fail.
- A records only used if no MX records were found.
-
- Extra debug information put in to try to determine the cause of some
- apparent premature timing out.
-
- Activity log notes in this document updated to cover bug reports.
-
-
- 1.03
- ----
-
- VRFY fixed again! It was rejecting non-local single recipient aliases
- because Newsbase was saying that the user was unknown.
-
-
- 1.02
- ----
-
- Fixed domain name processing to not add surplus > characters
-
- EXPN procession now works properly again
-
-
- 1.01
- ----
-
- Fixed acceptfrom and rejectfrom handling - the bitfield masks were
- the wrong way around
-
-
- 1.00
- ----
-
- TRACE removed from the sendmail transport!!
-
- maxhops added
-
- Vital missing headers are added to incoming mail
-
-
- 0.11
- ----
-
- You can disable the GUI by adding 'noiconbar' to the configuration file
-
- Some of the log messages are clearer
-
- Bug in sendmail transport file corrected
-
-
- 0.10
- ----
-
- Very simple Wimp interface added
-
- Some log messages have been changed to make them sound less fatal (some
- are purely informational but had alarming sounding overtones)
-
- in_smtpd's sendmail reads the smtp-conf file to determine how to send
- mail to single recipients, instead of defaulting to MX records (when
- no gateway can be found, and none was given in Newsbase, multiple
- mails are generated to all of the recipients via MX records)
-
-
-
- 0.09
- ----
-
- Multi-line responses were confusing the SMTP sender because I'd got a
- condition test round the wrong way :-(
-
- Lock files removed - the task list is scanned instead.
-
- Long lines were confusing things all over the place. Although illegal,
- some clients still generate this, so I allow them now too.
-
- The socket sender had every chance of crashing if a line was to be
- transmitted which was longer than 256 characters! This is now
- upped to 1024 characters (something which calling routines already
- enforce)
-
- SMTP Monitor uses an exponential backoff retry algorithm for sending mail
- when it is first started - it delays 30 seconds, then 1 minute, then 2,
- then 4, then 8, then 16, then every 30 minutes. It can still be launched
- manually by running !SendSMTP and will be launched whenever you send mail
- locally.
-
-
-
- Please e-mail me any problems: snb94r@ecs.soton.ac.uk
-
-
- --
- Stewart Brodie
- February 1997
-